A data storage server (“server”) is connected to physical data storage devices such as magnetic or solid state disk drives (“drives”) on which data is actually stored. The available data storage space of the drives is divided into one or more volumes by the server. A volume is a logical data storage container in which files can be stored. Each volume has an active filesystem which determines how the files are stored, accessed and modified, amongst other things. A persistent point in time image (“PPI”) of the active filesystem is called a snapshot. The creation of a snapshot does not typically involve the copying of any significant amount of data, but rather involves copying a very small amount of metadata of the active filesystem. Multiple snapshots and the active filesystem may share many of the same files and data blocks which make up those files.
Special files called virtual disks (“vdisks”) are created within a volume and are managed by the server. Some embodiments of vdisks may involve vdisks which are not based on a single file. Client computers can connect to the vdisks over a communications network using predefined protocols. Once the clients connect to the vdisks the clients can write data to and read data from the vdisks in the same manner as the clients can write data to and read data from locally attached drives. Vdisks are generally one of two different types, either Logical Unit Numbers (“luns”) or lun clones. A lun clone is a space saving copy of a lun and may share data blocks with the lun. The lun of which the lun clone is a space saving copy of is referred to as a backing lun. The only luns which may be backing luns are those luns within snapshots. The snapshot which contains a backing lun for a particular lun clone is referred to as the backing snapshot of that lun clone. When the lun clone is first created, the backing lun and the lun clone both share the same data blocks. The creation of a lun clone is an almost instantaneous process since the data blocks of the backing lun are not copied. Over time, as the lun clone is modified, the number of shared data blocks between the backing lun and the lun clone diminishes. Lun clones are very useful in situations where testing of data stored on a lun is desired without permanently modifying that data. For instance, a software application may be stored on the lun and used in a production environment. If it is desired to test an upgrade of the software application without disrupting the lun, a snapshot is created which contains the lun and a lun clone is created based on the lun within the snapshot. The software application can then be upgraded and tested on the lun clone without affecting the lun. The lun clone may then be deleted after the software upgrade has been verified to be problem free.
To protect against inadvertent data loss on the server, the data on the server may be backed up to another server. A server which backs up data to another server is referred to as a primary server and the server which stores the backed up data for the primary server is referred to as a secondary server. Luns on the primary server are preserved in a consistent state by creating a snapshot of the active filesystem, and then transferring the snapshot from the primary server to the secondary server. Of course, transferring an object in a computer context does not imply that the object transferred is deleted or otherwise removed from its source location, as in a physical context. The secondary server receives the transferred snapshot, restores the snapshot into the active filesystem and then creates a snapshot of the active filesystem in order to preserve the state of the active filesystem. In the event that data is inadvertently lost on the primary server, the data can be restored on the primary server by transferring the previously backed up snapshot from the secondary server to the primary server, and then restoring the transferred snapshot to the active filesystem.
Previously known techniques for backing up lun clones from a primary server to a secondary server did not preserve the space saving relationship between luns and lun clones on the secondary server, as shown in FIG. 1. A primary server 10 and a secondary server 12 each have a data storage space 14 which stores data for luns 16 and luns clones 18. Each lun clone 18 on the primary server 10 contains shared data 20 which is shared with a corresponding lun 16. The previous techniques for backing up the lun clones 18 resulted in the data of lun clones 18 (labeled as Lun Clones 1.1, 2.1 and 3.1) being copied into luns 16 (labeled as Lun 1.1, 2.1 and 3.1) on the secondary server 12. Since the lun clones 18 (Lun clones 1.1, 2.1 and 3.1) were copied to the secondary server 12 as luns 16 (Luns 1.1, 2.1 and 3.1), the space saving relationship between the lun clones 18 and the luns 16 was lost. The shared data 20 on the primary server 10 that is shared between the lun clones 18 and the luns 16 became duplicate data 22 on the secondary server, with both the luns 16 (Luns 1.0, 2.0 and 3.0) and the luns 16 (Luns 1.1, 2.1 and 3.1) having separate copies of the duplicate data 22. As a result of the luns 16 on the secondary server 12 having duplicate data 22, more data storage space 14 on the secondary server 12 was required than on the primary server 10 to backup the data from the luns 16 and the lun clones 18 of the primary server 10.
These and other considerations have led to the evolution of the present invention.